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support  for  intelligence  community  stakeholders  worldwide. 

Abstract 

Competition  is  repeatedly  cited  in  the  acquisition  world  as  a  powerful  tool,  if  not  the  most 
powerful  tool,  to  ensure  taxpayers  get  the  most  value  for  their  tax  dollars.  A  viable 
competition  package  (Request  for  Proposal  [RFP],  Statement  of  Work  [SOW],  Performance 
Work  Statement  [PWS],  etc.)  is  not  possible  without  having  adequate  technical  data, 
computer  software,  and  computer  software  documentation  to  provide  to  potential  competitors 
to  enable  them  to  develop  or  evolve  a  system  or  support  the  solution  needed.  This  paper  first 
presents  the  acquisition  professional  with  the  knowledge  to  more  effectively  evaluate 
intellectual  property  in  source  selections  to  ensure  the  Government  gets  the  intellectual 
property  rights  it  needs  to  procure,  support,  and  sustain  systems  the  warfighter  and  others 
need;  second,  provides  a  structure  and  process  to  get  these  “rights”  identified  on  contract 
while  providing  transparency  for  them  throughout  the  period  of  performance;  and,  finally, 
presents  a  different  way  to  look  at  the  “necessary”  rights  when  viewed  from  an  open  system 
architecture  perspective. 

Introduction 

Better  Buying  Power  (BBP)  2.0  challenged  the  Department  of  Defense  (DoD)  to  “do 
more  without  more.”  One  focus  area  was  to  “promote  effective  competition”  (Office  of  the 
Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  [USD(AT&L)],  2013, 
p.  17).  Competition  is  repeatedly  cited  in  the  acquisition  world  as  a  powerful  tool,  if  not  the 
most  powerful  tool,  to  ensure  the  taxpayer  gets  the  most  value  for  their  tax  dollars.  It  is  very 
difficult,  if  not  impossible,  however,  to  develop  a  viable  competition  package  (Request  for 
Proposal  [RFP],  Statement  of  Work  [SOW],  Performance  Work  Statement  [PWS],  etc.) 
without  having  adequate  technical  data,  computer  software,  and  computer  software 
documentation  to  provide  to  potential  competitors  to  enable  them  to  develop  or  evolve  the 
system  or  support  the  solution  needed.  To  this  end,  delivering  the  appropriate  volume  and 
content  of  technical  data  and  computer  software  that  are  necessary  to  compete,  support, 
and  sustain  weapon  systems  and  their  support  infrastructures  is  critical. 

Promoting  effective  competition  was  also  framed  in  the  context  of  using  Open 
Systems  Architecture  (OSA)  approaches  and  managing  technical  data  rights  to  foster  those 
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architectures  (OUSD[AT&L]),  2013,  p.  18).1  Put  quite  simply,  you  can’t  develop  and  maintain 
open  architectures  without  access  to  the  technical  data  and  software  they  rely  upon  or  at 
least  utilize  to  some  extent.  BBP  3.0  does  not  abandon  the  progress  of  the  two  previous 
BBP  releases.  Rather,  it 

continues  the  focus  on  continuous  improvement  with  a  new  emphasis  on 
initiatives  that  encourage  innovation  and  promote  technical  excellence  with 
the  overarching  goal  of  ensuring  that  the  United  States’  military  has  the 
dominant  capabilities  to  meet  future  national  security  requirements. 
(OUSD[AT&L],  2014,  p.  2) 

OSA  continues  to  be  a  BBP  focus  to  stimulate  technology  insertion  to  keep  pace  with 
technology  innovations  and  enable  the  design  agility  needed  to  keep  ahead  of  our 
adversaries.  We  simply  cannot  effectively  “refresh”  our  designs  without  the  tools  to  foster 
these  refresh  cycles.  The  modularity  of  OSA  not  only  stimulates  innovation,  but  fosters 
competition  as  well  from  new  entrants  to  the  market  from  which  to  leverage  not  only 
commercial  technology  but  new  designs  as  well. 

This  paper  is  not  a  “how-to  guide”  to  implement  OSA  from  a  technical  perspective.  It 
does,  however,  provide  an  approach  to  aid  acquisition  professionals  in  structuring  RFPs, 
evaluating  them,  and  making  best  value  award  decisions  in  competitive  acquisitions.  In 
other  words,  how  to  get  OSA  on  contract  more  effectively.  What  is  unique  in  this  approach  is 
that  it  fosters  significantly  improved  management  and  insight  of  technical  data  rights  and 
computer  software  toward  an  end  goal  of  implementing  an  open  systems  approach  both  for 
the  instant  contract  and  those  that  follow.  This  approach  results  in  the  program  managers 
and  their  acquisition  teams  knowing  exactly  what  intellectual  property  (IP),  which  includes 
not  only  non-commercial  data  rights  but  also  commercial  software,  commercial  technical 
data,  and  patented  inventions,  are  incorporated  into  a  contractor’s  technical  solution  and 
how  any  restrictions  impact  the  final  deliverables  from  a  future  support,  sustainment,  and 
competition  perspective. 

Background 

The  two  primary  parts  within  acquisition  regulations  discussed  herein  are  the  Federal 
Acquisition  Regulation  (FAR)  Part  15  (Contracting  by  Negotiation),  specifically,  Subpart  15.1 
Source  Selection  Processes  and  Techniques;  and  DoD  FAR  Supplement  (DFARS)  Part  227 
(Patents,  Data,  and  Copyrights),  specifically,  Subpart  227.71  (Rights  in  Technical  Data)  and 
Subpart  227.72  (Rights  in  Computer  Software  and  Computer  Software  Documentation).  It  is 
where  these  two  parts  of  the  acquisition  regulations  intersect  that  we  need  to  leverage  to 
ensure  the  Government  communicates  what  it  needs  with  respect  to  intellectual  property 
(IP).  Getting  the  IP  the  Government  needs  is  not  an  “option,”  as  the  DoDI  5000.2  clearly 
levies  this  responsibility  to  program  managers  where  it  states, 

Program  management  must  establish  and  maintain  an  IP  Strategy  to  identify 
and  manage  the  full  spectrum  of  IP  and  related  issues  (e.g.,  technical  data 
and  computer  software  deliverables,  patented  technologies,  and  appropriate 


1  The  essence  of  Open  Systems  Architecture  (OSA)  is  organized  decomposition,  using  carefully 
defined  execution  boundaries,  layered  onto  a  framework  of  software  and  hardware  shared  services 
and  a  vibrant  business  model  that  facilitates  competition.  For  a  full  description,  see  (DoD,  2013,  p.  iii). 
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license  rights)  from  the  inception  of  a  program  and  throughout  the  life  cycle. 
(OUSD[AT&L],  2015,  p.  76) 

This  “IP  Strategy”  can  only  be  effectively  executed  when  the  Government  knows 
where  IP  is  embedded  within  its  components,  items,  and  processes.  Program  managers  and 
their  acquisition  team  need  to  be  in  front  of  the  IP  challenge  at  the  beginning  of  acquisitions 
during  the  RFP  phase.  If  an  IP  Strategy  and  its  related  issues  related  to  missing  data, 
computer  software,  and  the  necessary  rights  and  licenses  to  use  them  is  implemented  well 
into  a  program’s  schedule,  it  is  too  late  to  capture  the  savings  possible  through  competition. 
Before  you  build  an  RFP,  you  have  to  first  have  a  Source  Selection  Plan  (SSP)  that  you 
must  follow  toward  contract  award.  A  brief  discussion  of  where  in  the  source  selection 
process  IP  can  be  better  communicated  and  evaluated  is  useful  to  provide  context  of  the 
recommended  solutions  presented  herein. 

The  Source  Selection  Process  and  IP  Focus  Areas 

A  top-level  source  selection  process  is  shown  in  Figure  1 .  This  figure  does  not 
attempt  to  capture  every  potential  step  and  process  (for  example,  conducting  clarifications 
or  awarding  without  discussions).  It  serves  only  to  highlight  where  this  paper  identifies  the 
impacts  evaluating  IP  has  on  the  overall  competitive  proposal/source  selection  process.  The 
light  shaded  boxes  reflect  the  key  areas  this  paper  will  elaborate  on.  The  SSP,  the 
importance  of  evaluating  and  scoring/rating  IP,  communicating  what  the  Government  wants 
through  the  RFP,  evaluating  proposals,  and  selecting  the  best  value  offer  using  IP  as  a 
decision  element  are  important  to  grasp  the  real  utility  of  leveraging  IP  in  competitive  source 
selections. 


Define 

Develop  Source  *FV(4S£Sv/fwi, 

i— >  Selection  Pfan  Mstwtxwte 

Issue  Draft  RFP 
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Requirement 

J££pl  Offerors  fvwitoa 
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Award  Without 

Request  Final 
Proposal 
Revisions  (FPRsJ 
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mpetitive  Range 
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Debrref 

Evaluate  FPRs 

Award 

->  U(5iwSl  . >  tost  award 

Requested 

Figure  1.  Source  Selection  Process 

Establishing  a  Sound  IP  Strategy  in  Source  Selections  and  Communicating  It 
Clearly  to  Industry  Is  Critical 

An  SSP  is  required  for  all  best-value,  negotiated,  competitive  acquisitions  under  FAR 
Part  15  (OUSD[AT&L],  2011).  It  is  within  the  SSP  where  IP  can  be  identified  as  part  of  the 
evaluation  criteria  as  either  a  factor  or  sub-factor.  The  more  importantly  IP  is  weighted  within 
the  total  set  of  criteria  will  directly  determine  how  much  attention  offerors  pay  to  it  with 
respect  to  winning  the  competition.  The  RFP  must  be  developed  to  align  exactly  with  the 
SSP  with  respect  to  process  and  the  criteria  to  evaluate  the  offerors’  proposals.  The  RFP 
must  also  clearly  communicate  (through  Section  L,  Instructions  to  Offerors)  how  to  structure 
and  present  their  proposal  with  respect  to  the  criteria  by  which  it  will  be  evaluated. 
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Evaluation  Criteria — Structure  With  Caution 

The  government  has  wide  latitude  with  which  to  establish  its  requirements  and  needs 
and  exercise  judgment  when  evaluating  offerors’  proposals.  The  General  Accountability 
Office,  in  adjudicating  hundreds  of  protests,  has  consistently  opined  that  in  reviewing  a 
protest  against  an  agency’s  evaluation  of  proposals,  it  will  not  substitute  its  (or  the 
protester’s)  judgment  for  that  of  the  agency;  rather,  it  will  examine  the  record  to  determine 
whether  the  agency’s  judgments  were  reasonable  and  consistent  with  the  stated  evaluation 
criteria  and  applicable  procurement  statutes  and  regulations.2  The  evaluation  of  proposals  is 
therefore  a  matter  within  an  agency’s  broad  discretion,  since  the  agency  ( not  Industry) 
[emphasis  added]  is  responsible  for  defining  its  needs  and  the  best  method  for 
accommodating  them.3  What  this  means  with  respect  to  establishing  IP  as  an  evaluation 
criteria  is  that  it  is  completely  acceptable  to  do  so.  Just  because  an  offeror  is  unhappy  with 
how  the  IP  (delivered  with  its  solution  to  the  Government’s  requirements)  was  scored,  does 
not,  in  and  of  itself,  establish  that  the  Government  acted  unreasonably.  The  Government  is 
simply  determining  that  the  solution  (with  the  related  IP)  did  not  represent  the  best  value  to 
the  Government.  All  that  being  said,  there  are  still  some  fundamental  pitfalls  that  can  derail 
an  otherwise  sound  IP  strategy. 

There  are  some  limitations  with  respect  to  IP  that  must  be  recognized  and  respected. 
The  Government  cannot  “force”  a  relinquishment  of  rights  to  data  (and  computer  software) 
that  was  independently  developed  at  private  expense.  This  restriction  is  well  founded  in  the 
U.S.  Code  and  the  DFARS.4  That  doesn’t,  however,  preclude  the  Government  from 
identifying  its  minimum  needs  for  IP  and  evaluating  the  impacts  restrictive  IP  elements  (data 
and  computer  software)  have  on  the  best  value  determination.  There  are  two  basic  ways  to 
evaluate  IP  in  the  competitive  proposal  process,  scoring  IP  as  a  criteria  (factor  or  subfactor) 
or  as  an  overall  IP  “Risk  Assessment.” 

Aligning  Evaluation  Criteria  With  Ratings  and/or  Risk  Assessments 

When  establishing  evaluation  criteria  with  their  respective  factors  and  subfactors,  the 
Government  must  communicate  not  only  how  ratings/scores  will  be  assigned,  but  also  when 
the  various  standards  have  been  met.  There  is  great  latitude  with  how  to  establish  scoring 
methodologies,  from  numerical,  algebraic,  narrative,  to  adjectival.  Since  IP  is  very  complex 
to  identify  and  evaluate,  adjectival  and  narrative  have  the  most  merit.  An  example  of  a 
previously  used  adjectival  rating  scale  can  be  found  in  Table  1 . 


2  See  GAO  Protest  Decision,  B-406505;  B-406405.2,  dated  May  21, 2012. 

3  See  GAO  Protest  Decision,  B-406505;  B-406405.2,  dated  May  21, 2012. 

4  See  10  U.S.C  2320(F)  and  DFARS  227.71 03-1  (c),  227.7203-1  (c). 
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Table  1.  Technical-Management  Rating  Scale* 


Color 

Definitions 

Blue 

Exceptional.  Offeror’s  proposal  demonstrates  an 
exceptional  understanding  of  the  requirements,  and  the 
approach  is  of  superior  quality.  Two  or  more  significant 
strengths  exist.  There  are  no  major  or  significant 
weaknesses  and  no  deficiencies  exist 

Teal 

Good.  Offeror’s  proposal  demonstrates  a  good 
understanding  of  the  requirements,  and  the  approach  is 
of  good  quality.  Strengths  clearly  outbalance  any 
weaknesses  that  exist.  There  are  no  significant 
weaknesses,  and  no  deficiencies  exist. 

Green 

Satisfactory.  Offeror’s  proposal  demonstrates  an 
acceptable  understanding  of  the  requirements,  and  the 
approach  is  of  satisfactory  quality.  There  may  be 
strengths  or  weaknesses  and  the  strengths  balance  the 
weaknesses.  No  deficiencies  exist. 

Yellow 

Marginal.  Offeror’s  proposal  demonstrates  a  marginal 
understanding  of  the  requirements,  and  the  approach  is 
of  poor  quality.  There  may  be  significant  weaknesses  or 
deficiencies.  Weaknesses  outbalance  strengths. 

Red 

Unsatisfactory.  Offeror’s  proposal  does  not 
demonstrate  an  understanding  of  the  requirements,  and 
the  approach  is  of  unacceptable  quality.  There  are 
significant  weaknesses  or  deficiencies.  Weaknesses 
negate  strengths. 

*  In  this  particular  example,  both  Technical  and  Management 
factors  were  scored  with  the  same  adjectival  rating  scale. 

One  of  the  subfactors  under  the  Technical-Management  Factor  was  Innovation 
Approach  (the  highest  of  three  total  subfactors).  Under  this  subfactor,  the  Government 
evaluated  the  offerors’  ability  to  identify  and  apply  innovative  methods  of  producing  domain 
understanding  and  domain  knowledge  from  multi-source,  multi-dimensional  data.  The 
Government  also  evaluated  the  offerors’  ability  to  identify  and  apply  innovative  methods  of 
automation  human-computer  interaction,  data  uncertainty  management,  and  data  pedigree 
maintenance.  Lastly,  the  Government  evaluated  the  offerors’  ability  to  minimize  technology 
transition  costs.  While  it’s  not  important  for  the  reader  to  understand  the  technical  nuances 
of  this  technical  factor,  it  is  important  to  focus  on  the  last  sentence  of  the  factor  from  an  IP 
perspective.  This  is  because  unless  the  Government  has  the  appropriate  rights  and  licenses 
to  the  IP  necessary  to  execute  the  offeror’s  technical  solution,  transitioning  the  technology 
developed  and  deployed  across  the  Government’s  organization  will  be  cost  prohibitive  and 
potentially  lead  to  a  long  term  sole  source  acquisition  situation. 

To  ensure  that  IP  independently  developed  at  private  expense  (as  discussed  earlier) 
is  not  a  “condition  of  offer”  or  that  the  solicitation  “forces”  a  relinquishment  of  the  same,  the 
“standards”  by  which  the  subfactors  will  be  evaluated  against  must  clearly  convey  this.  To 
this  end,  the  standards  associated  with  the  above  Innovative  Approach  subfactor  stated  that 
the  standard  would  be  met  when  the  Offeror 

described  the  extent  to  which  the  rights  in  Technical  Data  (TD),  Computer 
Software  (CS),  and  Computer  Software  Documentation  (CSD),  and 
inventions/patents  offered  to  the  Government  ensured  unimpeded, 
innovative,  and  cost  effective  production,  operation,  maintenance,  and 
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upgrade  of  the  [System  Name]  processing  prototypes  throughout  its 
lifecycle;  allow  for  open  and  competitive  procurement  of  [System  Name] 
enhancements;  and  permit  the  transfer  of  [System  Name]  TD,  CSD,  and  CS 
to  other  systems  or  platforms. 

Note  the  power  of  this  one  standard.  In  it,  nine  best  value  tradeoffs  can  be  identified 
that  are  directly  attributable  to  IP  rights  and  licenses  (unimpeded,  innovative,  cost  effective, 
production,  operations,  maintenance,  upgrade,  future  competitions,  transfer  to  other 
systems  or  platforms). 

The  standard  went  on  to  ensure  that 

proposals  will  not  be  rated  less  that  SATISFACTORY  on  this  standard  solely 
because  an  offeror  does  not  offer  a  price  for  all  items  delivered  with 
Government  Purpose  Rights.  However,  rating  on  this  factor  for  proposals  to 
deliver  TD,  CSD,  and  CS  with  less  than  the  minimum  rights  specified  for  the 
Government  by  applicable  statute  (10  U.S.C.  2320)  and  regulation  DFARS 
252.227-7013,  252.227-7014,  and  252.227-7015  may  be  negatively 
impacted.  For  non-commercial  acquisitions,  these  rights  include  Unlimited 
Rights  in  TD,  CS,  and  CSD  as  specified  in  DFARS  252.227-7013  &  252.227- 
7014,  Limited  Rights  in  TD  as  specified  in  DFARS  252.227-7013,  and 
Restricted  Rights  in  CS  as  specified  in  DFARS  252.227-7014.  The  minimum 
rights  considered  for  TD  associated  with  commercial  item  acquisitions  are 
specified  in  DFARS  252.227-7015.  For  commercial  CS  acquisitions, 
evaluation  of  the  offered  license  rights  will  assess  the  licenses  customarily 
provided  to  the  public  with  respect  to  their  consistency  with  Federal 
procurement  law  and  satisfaction  of  Government  user  needs  as  set  forth  in 
the  solicitation. 

The  key  to  having  enough  insight  into  the  offeror’s  proposal  regarding  the  IP  strategy 
reflected  in  the  subfactor  and  its  related  standard  is  to  “map”  the  IP  within  the  proposal.  This 
will  be  discussed  later  on.  An  alternative  to  “scoring”  IP  is  to  evaluate  IP  from  an  overall 
“Risk”  perspective.  To  this  end,  an  IP  Risk  Evaluation  example  is  presented  next. 

To  simplify  the  evaluation  of  IP  in  a  source  selection,  some  acquisition  teams  have 
chosen  to  assess  overall  IP  “Risk”  as  reflected  in  an  offeror’s  proposed  technical  solution. 

As  example  of  this  was  where  the  Government  evaluated  Intellectual  Property  Risk  as 

the  extent  to  which  the  Intellectual  Property  in  technical  data,  computer 
software  and  computer  software  documentation  and  inventions/patents 
offered  to  the  Government  will: 

•  Ensure  unimpeded,  innovative  and  cost  effective  production,  operation, 
maintenance,  and  upgrade  of  the  capability/service  throughout  the 

•  [System  Name]  life  cycle 

•  Allow  for  open  and  competitive  procurement  of  enhancements;  and  will 
permit  the  transfer  of  technical  data  of  non-proprietary  object  and  code  and 
source  code  to  other  contractors  for  use  on  other  systems  or  platforms.  (DoD, 
2013) 

This  example  used  a  Risk  Rating  table  as  shown  in  Table  2. 


MSi 

TMlBWlTt*  MH 


-370- 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


Table  2.  Intellectual  Property  Risk 


Risk  Rating 

Definition 

High 

High  probability  for  schedule  disruption,  cost  growth,  and/or  performance  impact. 
Extensive  use  of  highly  restrictive  commercial  or  proprietary  technical  data,  computer 
software,  and  computer  software  documentation,  offered  to  the  Government  will 
definitely  result  in  impeded,  unimaginative,  and  cost  prohibited  production,  operation, 
maintenance,  and  upgrade  of  the  capability/service  throughout  the  [System  Name]  life 
cycle,  will  impede  open  and  competitive  procurement  of  enhancements,  and  inhibit  the 
transfer  of  the  non-proprietary  object  code  and  source  code  to  other  contractors  for  use 
on  other  systems  or  platforms.  Mitigation  actions  for  commercial  technical  data 
computer  software,  and  computer  software  documentation  terms  and  conditions  that 
are  contrary  to  Federal  law  or  are  inconsistent  with  all  requirements  of  this  RFP  are  not 
identified.  Risk  may  be  unacceptable  even  with  special  contractor  emphasis  and  close 
Government  monitoring.  Program  success  is  jeopardized. 

Moderate 

Moderate  probability  for  schedule  disruption,  cost  growth,  and/or  performance  impact. 
Less  than  Government  Purpose  Rights  in  technical  data,  computer  software,  and 
computer  software  documentation,  offered  to  the  Government  may  impede,  innovative, 
and  cost  effective  production,  operation,  maintenance,  and  upgrade  of  the 
capability/service  throughout  the  [Program  Name]  life  cycle,  may  impede  open  and 
competitive  procurement  of  enhancements,  and  may  impede  the  transfer  of  the  non- 
proprietary  object  code  and  source  code  to  other  contractors  for  use  on  other  systems 
or  platforms.  Commercial  technical  data  computer  software,  and  computer  software 
documentation  terms  and  conditions  may  be  contrary  to  Federal  law,  cannot  be 
amended,  and  may  lead  to  schedule  disruption,  cost  growth,  and/or  performance 
impact.  Mitigation  actions  for  these  commercial  technical  data,  computer  software  and 
computer  software  documentation  terms  and  conditions  that  are  contrary  to  Federal 

Law  or  are  inconsistent  with  all  reguirements  of  this  RFP  have  not  been  adequately 
identified.  Special  contractor  emphasis  and  close  Government  monitoring  will  probably 
overcome  difficulties  without  significantly  impacting  program  success. 

Low 

Low  probability  for  schedule  disruption,  cost  growth,  and/or  performance  impact. 
Government  Purpose  Rights  or  Unlimited  Rights  in  technical  data,  computer  software, 
and  computer  software  documentation,  offered  to  the  Government  will  definitely  ensure 
unimpeded,  innovative,  and  cost  effective  production,  operation,  maintenance,  and 
upgrade  of  the  capability/service  throughout  the  [Program  Name]  life  cycle,  allow  for 
open  and  competitive  procurement  of  enhancements,  and  permit  the  transfer  of  the 
non-proprietary  object  code  and  source  code  to  other  contractors  for  use  on  other 
systems  or  platforms.  Normal  contractor  effort  and  routine  Government  monitoring 
should  overcome  any  difficulties.  Mitigation  actions  have  been  adequately  identified  for 
commercial  terms  and  conditions  that  are  contrary  to  Federal  law  or  are  inconsistent 
with  all  requirements  of  this  RFP,  Program  success  is  likely. 

The  “risk  evaluation”  approach  implemented  by  Table  2  provides  for  assessing  the 
impact  of  IP  on  the  overall  proposed  solution  across  all  the  technical  areas,  vice  a  specific 
factor  or  subfactor  as  presented  earlier.  This  gives  the  evaluation  team  even  more  flexibility 
and  is  actually  easier  to  document  in  the  IP  evaluation.  While  both  approaches,  the  “factor” 
approach  and  the  “risk”  approach,  have  great  merit,  they  both  require  adequate  clarity  with 
respect  to  the  identification  of  the  IP  throughout  the  offeror’s  proposal.  This  is  facilitated  by 
the  standard  “assertions  process”  required  in  DFARS  252.227-7017  and  standard  Section 
K,  Representations  and  Certifications,  Provisions,  but  the  methodology  presented  herein 
takes  these  longstanding  processes  to  a  much  higher  level. 

Evaluating  Initial  Proposals 

Figuring  out  where  IP  is  buried  within  a  contractor’s  proposal,  or  more  importantly, 
within  the  proposed  solution,  is  not  easy.  This  is  because  the  primary  enabling  clauses  rely 
upon  Section  K,  which  normally  brings  in  the  Assertions  Clause,  252.227-7017  (the  -7017 
clause),  the  Prior  Delivery  Clause,  252.227-7028  (the  -7028  clause),  and  the  required  FAR 
assertions  pursuant  to  the  necessary  Patent  clauses  in  the  contract  when  applicable 
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(52.227-6,  52.227-7,  52.227-9,  52.227-10). 5  Unfortunately,  even  though  the  assertions 
become  a  part  of  the  resulting  contract,  many  elements  of  Section  K  are  long  forgotten  after 
contract  award.  The  net  result  is  that  IP  is  many  times  a  proposal  element  that  is 
overlooked,  and  it  may  come  back  to  haunt  the  Government  when  the  “impact”  of  the 
assertions  become  apparent  upon  delivery  or  earlier  during  contract  performance.  What  is 
needed  is  a  better  methodology  and  form  with  which  to  identify  and  evaluate  IP  during  the 
proposal  evaluation  process.  One  proven  method  is  to  leverage  the  assertions  process. 

Leveraging  the  “Assertions  Process”  to  Expand  Clarity  and  Purpose 
The  Assertions  Process 

IP  can  be  some  of  a  company’s  most  valuable  assets,  the  relinquishment  of  which 
can  significantly  impact  not  only  their  profitability,  but  their  long-term  survival  as  well.  As  a 
result,  it  is  in  their  best  interests  to  protect  them  to  the  maximum  extent  possible.  While  only 
one  small  component  of  data  rights  management,  the  “assertion  step”  is  important  to 
understand  both  pre  and  post  award  as  there  are  different  standards  and  responsibilities 
tied  to  each.  Unfortunately,  the  assertions  required  by  the  -7017  clause  leaves  a  lot  of 
uncertainly  with  respect  to  just  “where”  the  restricted  elements  reside  in  the  technical 
solution  or  services  provided.  The  “Intellectual  Property  Attachment”  methodology  provided 
herein  represents  a  best  practice  that  “maps”  the  contract  line  items  (CLINS),  the  Contract 
Data  Requirements  List  (CDRL)  items,  the  minimum  data  rights  the  Government  has 
determined  necessary  for  each  deliverable,  the  Statement  Of  Work  (SOW)/Performance 
Work  Statement  (PWS),  the  Data  Rights  that  will  be  delivered;  and  other  IP  (patented 
inventions),  all  in  one  contract  attachment  with  seven  tables  that  live  throughout  the  life  of 
the  contract.  This  approach  facilitates  efficient  and  thorough  evaluation  of  IP  both  for  initial 
proposals  and  final  proposal  revisions.  It  also  establishes  an  additional  vantage  point  from 
which  to  eliminate  weak  proposals  from  the  competitive  range  and  to  establish  another 
element  of  the  “responsiveness”  determination  of  proposals. 

Rather  than  attempt  to  explain  all  the  nuances  and  entitlements  of  the  various 
categories  of  data  rights,  commercial  technical  data  and  software  terms  and  conditions  and 
patents/inventions,  which  are  beyond  the  scope  of  this  paper,  the  important  takeaway  is  that 
the  acquisition  professional  must  clearly  understand  the  nature  and  content  of  the  technical 
data  and  computer  software  (both  commercial  and  non-commercial)  they  identify  as  required 
to  meet  their  minimum  needs  to  execute  their  particular  contract/program. 

What  may  not  be  so  obvious  to  the  acquisition  professional  is  that  assertions  are  a 
critical  precursor  to  being  able  to  mark  any  deliverable  containing  technical  data  or  computer 
software  with  any  restrictive  marking,  post  award.  In  other  words,  if  a  deliverable  contains 
such  non-commercial  intellectual  property,  identifying  the  items,  the  basis  for  the  restrictive 
marking  and  what  restrictive  category  is  applicable  is  required  before  delivering  with  a 
restrictive  marking  affixed  to  the  specific  data  items.  The  DFARS  requires  these  assertions 
be  furnished  to  the  Government  and  identified  in  “an  attachment”  to  the  contract  prior  to  the 
delivery  of  any  data  with  restrictive  data  (DFARS  227.227-701 3(e)(2)).  The  DFARS  goes  on 


5  Managing  inventions  and  the  patents  that  register  them  is  not  a  primary  focus  of  this  paper  due  to 
the  complexities  of  this  topic  and  page  limitations.  The  identification  of  them  is  however  important  and 
is  presented  later. 
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to  cite  the  -7017  clause  as  the  provision  to  facilitate  this  identification  process,  or  for  our 
purpose  here  the  assertions  necessary  as  a  precursor  to  affixing  restrictive  markings  on 
deliverables  (DFARS  227-71 03-3(b)).  This  Assertions  List  then  becomes  attached  to  the 
contract  (DFARS  227-71 03-1 0(a)(3)). 

In  like  fashion,  the  DFARS  requires  the  identification  of  computer  software  and 
computer  software  documentation  to  be  furnished  with  restrictions  prior  to  delivery  (DFARS 
252.227-7014(e)(2)).  As  with  Technical  Data,  the  -7017  clause  is  used  again  to  facilitate  the 
same  due  diligence  actions  by  the  contractor  discussed  earlier.  It  bears  repeating  again  that 
unless  a  restriction  is  asserted,  no  restrictive  markings  may  be  affixed  to  the  final  software. 
(This  is  normally  done  via  “code  headers”  within  the  software  itself  and  the  marking  of  the 
physical  documentation  of  the  software.)  Both  Government  and  contractor  alike  should  take 
extreme  care  during  the  software  acceptance  process  to  ensure  that  non-commercial 
computer  software  is  scanned  to  identify  any  internal  restrictive  markings  as  they  can 
coexist  with  a  transmittal  letter  that  alludes  to  something  else.  Once  incongruent  markings 
are  identified,  the  corrective  actions  may  be  invoked  as  set  forth  in  both  the  -7013  clause 
and  the  -7014  clause. 

Before  we  get  to  the  details  of  the  Assertion  List  itself  developed  pursuant  to  the  - 
7017  clause,  the  causal  link  between  assertion  and  delivery  is  useful  to  revisit.  If  you  read 
both  the  -7013  and  -7014  clauses  carefully  you  will  note  that  the  activity  of  delivery  is  woven 
throughout.  Thus  the  action  of  delivery  is  required  to  empower  the  Government  to  assert  its 
data  rights  on  the  non-commercial  Technical  Data  or  Computer  Software  in  question.  As 
explained  previously,  any  restrictions  must  be  “asserted”  prior  to  any  such  delivery.  But 
before  any  such  assertions  may  be  made,  the  specific  technical  data  or  computer  software 
must  be  “identified”  as  required  for  delivery.  This  is  an  important  sequence  of  events  that 
must  take  place  to  effectively  manage  data  and  the  protection  thereof.  In  other  words,  no 
assertion,  no  restrictive  marking  authorized  if  you  are  the  contractor.  But  if  you  are  the 
Government,  beware,  because  without  a  requirement  for  “delivery”  the  contractor  is  not 
bound  to  identify  or  assert  any  restrictions.  Only  if  delivery  is  later  called  for  (via  deferred 
ordering)  or  identified  as  a  post  award  assertion  (which  has  more  strict  limitations  than  pre¬ 
award  assertions)  will  the  identification  and  the  restrictions  be  brought  to  light.6 

Let’s  now  turn  to  one  of  the  key  elements  of  the  discussion,  namely,  the  Assertions 
List,  or  more  importantly  the  -7017  clause  elements  that  lead  to  the  “List”  or  “Attachment” 
itself.  This  is  the  traditional  methodology  (combined  with  attaching  commercial  software 
licenses  to  the  contract  and  citing  patent  royalty  information  in  Section  K,  as  discussed 
earlier). 

Since  this  is  so  critical  to  the  discussion  here,  the  elements  of  the  clause  are 
provided  in  Table  3. 


6  See  DFARS  252.227-701 3(e)(3),  252.227-7014(e)(3),  and  252.227-701 8(e)(3). 
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Table  3.  -7107  Clause  Elements 

(DFARS  252.227-701 7(e)(3))7 


The  Offeror  asserts  for  itself,  or  the  persons  identified  below,  that  the  Government’s  rights  to  use,  release,  or 
disclose  the  following  technical  data  or  computer  software  should  be  restricted: 


Technical  Data  or 
Computer  Software 
to  be  Furnished 

With  Restrictions* 

Basis  for 
Assertion" 

Asserted  Rights 
Category*** 

Name  of  Person 
Asserting 
Restrictions**** 

(LIST)*™ 

(LIST) 

(LIST) 

(LIST) 

Tor  technical  data  (other  than  computer  software  documentation)  pertaining  to  items,  components,  or 
processes  developed  at  private  expense,  identify  both  the  deliverable  technical  data  and  each  such 
item,  component,  or  process.  For  computer  software  or  computer  software  documentation,  identify  the 
software  or  documentation. 

“Generally,  development  at  private  expense,  either  exclusively  or  partially,  is  the  only  basis  for 
asserting  restrictions.  For  technical  data,  other  than  computer  software  documentation,  development 
refers  to  development  of  the  item,  component,  or  process  to  which  the  data  pertain.  The  Government’s 
rights  in  computer  software  documentation  generally  may  not  be  restricted.  For  computer  software, 
development  refers  to  the  software.  Indicate  whether  development  was  accomplished  exclusively  or 
partially  at  private  expense.  If  development  was  not  accomplished  at  private  expense,  or  for  computer 
software  documentation,  enter  the  specific  basis  for  asserting  restrictions. 

"‘Enter  asserted  rights  category  {e.g.,  Government  purpose  license  rights  from  a  prior  contract,  rights 
in  SBIR  data  generated  under  another  contract,  limited,  restricted,  or  Government  purpose  rights  under 
this  or  a  prior  contract,  or  specially  negotiated  licenses). 

'"‘Corporation,  individual,  or  other  person,  as  appropriate. 

""‘Enter  ■'none"  when  all  data  or  software  will  be  submitted  without  restrictions. 

Date  _ 

Printed  Name  and  Trtle  _ 


Signature 


Columns  two  through  four  are  the  easiest  to  deal  with.  Column  four  is  very 
straightforward:  who  is  the  right  person  to  sign  off.  Column  three  is  fairly  simple  as  well:  it’s 
either  Restricted  Rights  (for  software),  Limited  Rights  (for  technical  data,  (SBIR  Rights),  or 
Government  Purpose  Rights  (where  mixed  funds  are/were  used).  Column  two,  the  basis 
column,  is  pretty  straightforward  as  well,  and  it  usually  reads  “Independently  Developed  at 
Private  Expense”  or  “Jointly  Developed  with  Contractor  and  Governments  funds.”  If  you  look 
at  the  information  sought  in  column  one,  however,  it  may  be  interpreted  in  some  instances 
ambiguously.  Just  what  is  required  to  “identify  the  technical  data,  computer  software  or 
computer  software  documentation”?  An  ambiguous  assertion  example  could  be  “All  XYZ 
software  utilized  in  the  ABC  assembly.”  This  “notional”  top  level  data  description  is  extremely 


7  Note  that  the  -7013,  -7014,  and  -7018  clauses  all  have  an  identical  table  with  some  of  the  instruction 
language  that  is  to  be  used  for  post  award  assertions. 
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problematic  for  two  main  reasons.  First,  the  Government  has  no  clue  “what”  software  is 
being  restricted  (assuming,  of  course,  Column  three  would  indicate  “Restricted  Rights”),  and 
second,  the  Government  really  doesn’t  know  clearly  “what”  software  it  really  should  be 
protecting  with  that  level  of  restriction,  where  within  the  system  or  architecture  design  the 
restricted  software  resides,  nor  what  it  is  really  getting  for  its  money.  True,  it  is  easy  to 
simply  say  “all,”  but  is  it  fair  and  accurate?  Most  would  agree,  it’s  not.  You  can’t  really 
determine  what  you  “need”  to  field,  support,  and  sustain  a  system  without  knowing  what  you 
“have”  to  begin  with  (Pickarz,  September  2012).  In  this  instance,  you  just  don’t  know  and 
most  importantly,  you  have  no  baseline  at  contract  award  from  which  to  later  determine  what 
changes  the  Government  has  funded  and  may  have  unlimited  rights  to.8  A  huge  entitlement 
may  be  lost  from  simply  not  paying  attention  to  the  assertions  contained  in  the  Assertions 
List.  The  solution  to  this  dilemma  is  actually  quite  simple.  Namely,  make  the  instructions 
unequivocally  clear.  A  formal  deviation  to  the  clause  is  probably  not  a  timely  solution.  A 
better  solution  is  clearer  instructions  to  the  contractor  in  the  solicitation  in  Section  L 
(Instructions  to  Offerors)  with  a  resultant  attachment  to  the  contract  that  documents  the 
technical  data  and  computer  software  and  their  respective  rights  to  be  given  to  the 
Government.  It  is  much  better  to  articulate  just  what  you  expect  the  contractor  to  deliver  in 
their  proposal  rather  than  have  them  guess.  For  the  example  earlier,  the  software  version(s), 
and/or  dates  should  be  given  to  clearly  identify  just  what  will  be  restricted  upon  delivery. 

Even  better,  if  you  make  clarity  of  the  assertions  a  condition  of  offer,  contractors  will  always 
comply  or  possibly  lose  the  award.  Let  me  be  clear,  however,  as  the  DFARS  deals  with  this 
very  situation  where  it  states, 

If  an  offeror  fails  to  submit  the  attachment  or  fails  to  complete  the  attachment 
in  accordance  with  the  requirements  of  the  solicitation  provision,  such  failure 
shall  constitute  a  minor  informality.  Provide  offerors  an  opportunity  to  remedy 
a  minor  informality  in  accordance  with  the  procedures  at  FAR  14.405  or 
15.607.  An  offeror’s  failure  to  correct  the  informality  within  the  time  prescribed 
by  the  contracting  officer  shall  render  the  offer  ineligible  for  award.  (DFARS 
227.71 03-1 0(a)(1)) 

Note  that  while  clarity  would  be  considered  a  “minor  informality,”  failure  to  correct  this 
shall  render  the  offer  ineligible  for  award.  Another  key  point  is  that  a  minor  informality  could 
be  resolved  as  a  “minor  error”  pursuant  to  a  “clarification”  vice  a  “discussion”  point,  thereby 
preserving  to  ability  to  award  without  discussions  should  this  be  provided  for  in  the 
solicitation  (FAR  15.306(a)(2)).  At  the  end  of  the  day,  additional  emphasis  in  the  instructions 
for  completing  the  assertions  goes  a  long  way  to  enable  the  Government  to  later  assert  the 
rights  it  has  paid  for. 

The  Intellectual  Property  Attachment — Mapping  Critical  IP  Artifacts 

Non-commercial  technical  data  and  computer  software  assertions  are  really  only  part 
of  the  intellectual  property  portfolio  as  there  are  numerous  commercial  technical  data  and 
computer  software  artifacts,  and  in  many  cases  previously  developed  inventions,  that  are 
relevant  to  Government  contracts.  The  answer  to  the  question,  “What  do  I  have?”  is 
important  not  only  at  contract  award  but  throughout  contract  performance  as  the 


8  See  DFARS  252.227-701 3(b)(1),  252.227-7014(b)(1). 
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deliverables  from  one  contract  provide  the  building  blocks  for  another  contracts  and  their 
programs/projects.  All  this  assertion  information  can  be  captured  in  one  place  both  to 
evaluate  the  proposal  and  then  continue  throughout  contract  performance  as  a  living 
document.  This  is  accomplished  by  adding  an  “Intellectual  Property  Volume”  to  your 
solicitation  and  the  resulting  “Intellectual  Property  Attachment”  to  the  awarded  contract. 

This  original  idea  was  first  promulgated  by  Space  and  Missile  Center  (SMC)  in  Los 
Angeles  and  presented  in  the  SMC  Office  of  the  Staff  Judge  Advocate  Guide  Acquiring  and 
Enforcing  the  Government’s  Rights  in  Technical  Data  and  Computer  Software  Under 
Department  of  Defense  Contracts:  A  Practical  Handbook  for  Acquisition  Professionals 
(Space  and  Missile  Center  [SMC]  Office  of  the  Staff  Judge  Advocate,  March  2014).  Now  in 
its  Sixth  edition,  this  somewhat  daunting  document  may  seem  to  be  a  bit  difficult  to  review  at 
first,  but  searching  for  the  “Data  Rights  Attachment”  will  get  you  to  most  of  the  components 
discussed  herein.  For  the  purposes  of  this  paper,  I  will  take  SMC/JA’s  approach  and  expand 
it  to  provide  a  comprehensive  “Volume”  to  the  proposal  that  lays  out  not  only  the  Data 
Rights  attributable  to  the  effort  but  other  areas  of  intellectual  property  as  well.  To  do  this,  an 
Intellectual  Property  Volume  is  required  from  offerors.  This  volume  would  be  structured  as 
follows: 


Volume  “X” — Intellectual  Property9 

•  Table  1 — Data  Rights  Summary:  Non-Commercial  Technical  Data  and 
Computer  Software  &  Computer  Software  Documentation 

•  Table  2 — Commercial  Technical  Data  and  Computer  Software  &  Computer 
Software  Documentation 

•  Table  3 — Assertions  List:  Non-Commercial  Technical  Data,  Computer 
Software,  and  Computer  Software  Documentation 

•  Table  4 — Specifically  Negotiated  Licenses  (Special  Licenses  to  Non¬ 
commercial  Technical  Data  and  Computer  Software) 

•  Table  5 — Rights  in  Background  Inventions 

•  Table  6 — Third  Party  Patent  Rights  and  Royalties 

It  helps  to  visualize  the  Intellectual  Property  Volume  approach  so  the  following 
notional  tables  with  example  deliverable  technical  data  and  computer  software  deliverables 
are  provided.  The  various  elements  of  the  tables  and  their  mapping  functions  will  be 
discussed. 


9  While  this  paper  focuses  on  “data  rights,”  Tables  6  and  7  are  provided  and  briefly  discussed  to  add 
the  listing  of  any  relevant  inventions  (Patents)  used  in  the  contractor’s  proposed  solution.  This 
incorporation  then  provides  a  comprehensive  IP  attachment  to  the  contract. 
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Table  4.  Data  Rights  Summary 

Non-Commercial  Technical  Data  and  Computer  Software  and  Computer 

Software  Documentation 


Co)  1 

Col.  2 

Col  .  3 

Col.  4 

Col.  5 

Col.  61 

Col.  7 

Col,  8 

Col.  9 

CLIN 

CDRL 

CDRL 

Title 

SOW/PWS 

Paragraphs 

Govern  me  ntf  s 
Minimum 
Rights 
Needed 

Offerors 

Normally 

Asserted 

Data 

Rights 

Offeror's 

Proposed 

Data 

Rights 

Explanatory 

Notes3 

Price/4 

Est, 

Cost 

0002 

AQ001 

Computer 

Software 

3.1.5 

Government 

Purpose 

Rights 

Offeror 

To 

Complete 

Offeror  To 
Complete 

N/A 

0002 

A0 002 

User 

Manuals 

3.1.4 

Unlimited 

Rights 

N/A 

Unlimited 

Rights2 

N/A 

0002 

A0003 

Contract 

Funds 

Status 

Report 

3,1.6 

N/A 

N/A 

N/A 

N/A 

0002 

AOOOn 

Title 

Para  Nr.  V 

N/A 

1 .  This  column  is  normally  used  for  competitive  Requests  for  Proposals  (RFPs).  Here  the  offeror(s)  indicate 
wfiat  their  usual  entitlements  are  for  the  respective  data  deliverable.  For  example,  if  the  data  was 
independently  developed  at  private  expense,  Restricted  Rights  (Software)  and  Limited  Rights  (Technical 
Data)  are  usually  appropriate  It  is  important  to  note  that  contractors  cannot  be  forced  to  relinquish  their 
rights  related  to  independently  developed  data  and  this  should  be  clearly  stated  in  the  RFP  They  arer 
however,  able  to  propose  higher  levels  of  data  rights  in  order  to  be  more  competitive  in  the  marketplace 
which  is  facilitated  by  Column  7  in  the  table  above,  in  both  instances,  the  offeror  fills  in  these  blocks  of  the 
table. 

2.  In  this  instance,  the  Government  has  filled  in  the  table  because  it  has  determined  that  the  User  Manuals 
constitute  Operation,  Maintenance,  Installation,  and  Training  (OMIT)  data  and  should  be  delivered  with 
Unlimited  Rights  in  accordance  with  10  U.S.C.  (a)(2)(CXiii).  In  other  words,  the  offerors  don't  get  to  restrict 
the  data,  nor  do  they  get  to  propose  their  "usual  rights  *  If  there  is  a  disagreement,  the  offeror  will  note  it  in 
Column  8,  and  perhaps  the  RFP  can  provide  for  Data  Rights  Options  to  pnce  out  additional  entitlements  the 
Government  may  purchase  if  the  Government's  identified  minimum  rights  cannot  be  offered  in  the 
established  line  item  prices. 

3.  Column  8  affords  offerors  the  opportunity  to  explain  why  they  will  not  provide  the  required  data  item  with  the 
indicated  Government  rights.  It  also  affords  the  opportunity  to  propose  a  "Special  License."  Special  licenses 
are  cited  in  Table  8. 

4.  The  Price/Estimated  Cost  column  is  only  necessary  when  separately  pricing  data  items.  It  is  important  to 
note  that  when  separately  priced  data  items  are  required,  additional  pricing  instructions  in  Section  L  are 
necessary  to  guide  offeror. 

As  you  can  see  from  the  Data  Rights  Summary  table,  the  data  rights  the  Government 
will  receive  are  clearly  “mapped”  to  the  contract’s  Contract  Line  Items  (CLINs),  Contract 
Data  Requirements  Lists  (CDRLS),  and  the  SOW/PWS.  CLIN  0002  in  this  particular 
solicitation  was  for  “Data,”  and  a  few  notional  items  are  presented.  But  there’s  some 
important  nuances  to  take  note  of  that  reflect  the  true  power  of  this  approach.  Note  first  that 
the  Government  has  clearly  identified  what  its  minimum  needs  are  for  this  acquisition  in 
Column  5.  Note  also  that  the  User  Manuals  constitute  OMIT  data,  which  entitles  the 
Government  to  Unlimited  Rights,  so  this  cell  in  the  table  has  been  “pre-filled”  to  establish  this 
entitlement.  The  Contract  Funds  Status  Report  (CFSR)  is  marked  N/A.  This  is  because  the 
CFSR  constitutes  financial  data  that  is  incidental  to  contract  administration  and  outside  the 
definition  of  “Technical  Data,”  which  triggers  the  applicability  of  the  various  rights  outlined  in 
the  clauses.  Finally,  Column  8  provides  the  ability  for  offerors  to  explain  why  the  rights 
proposed  do  not  meet  the  Government’s  minimum  needs  (again  to  preclude  forcing  the 
relinquishment  of  rights  to  independently  developed  technical  data  or  computer  software.) 
This  table  from  the  proposal  will  become  an  attachment  to  the  contract  and  a  “living” 
document  (as  will  all  the  tables  discussed  here)  to  provide  for  adding  post  award  assertions 
and  afford  the  Government  complete  Intellectual  Property  situational  awareness. 

Table  5  provides  the  insight  to  any  commercial  technical  data  or  computer  software 
the  contractor  must  deliver  under  the  contract.  This  table  contains  nine  columns. 
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Table  5.  Commercial  Technical  Data,  Computer  Software,  and  Computer 

Software  Documentation 


Col.  1 

Col.  2 

Col.  3 

Col.  41 

COL  5 

Col.  6 

Col.  7 

Col.  8 

Col  9 

CUN 

CDRL 

SOW/PWS 

Paras 

Data 

Item 

Title/ 

Subtitle 

Technical 

Data/ 

Software 

Application 

Name 

Vendor 

Name 

License 

No. 

Quantity  of 
Licenses 
(If  applicable) 

Price/ 

Estimated 

Cost 

0002 

A0QQ1 

Para  Nrs. 

0002 

A0002 

Para  Nrs. 

1  The  instructions  for  this  column  in  Section  L  must  clearly  articulate  the  requirement  foe  clarity  and 
thoroughness  in  the  item  desenptions  for  the  reasons  mentioned  earlier  It  needs  to  be  made  clear  to 
offerors  that  cryptic  and  incomplete  descriptions  may  render  their  offer  non- responsive  to  the  solicitation,  in 
addition,  if  firmware  is  to  be  delivered,  the  Data  Item  Title  should  include  the  CLIN  Noun  Description  that  the 
firmware  will  be  embedded  into. 

In  like  fashion  of  the  other  tables,  the  first  three  columns  provide  for  CLINs,  CDRLS 
and  SOW/PWS  paragraphs  that  are  mapped  to  the  commercial  technical  data  and 
commercial  computer  software  that  are  to  be  delivered  that  is  provided  for  in  the  proposal. 
Instructions  in  Section  L  will  again  guide  offerors  how  to  populate  the  table.  The 
Government  needs  to  ensure  that  identifying  commercial  software  is  not  enough,  and  Open 
Source  Software  (OSS)  and  other  openly  shared  software  must  also  be  identified  since  they 
are  also  commercial  products  in  nature.  This  is  because  even  though  a  software  artifact  may 
be  “open,”  it  still  has  terms  and  conditions  by  which  it  must  be  shared.  The  commercial 
license  terms  can  be  problematic  and  the  Government  may  have  concerns  regarding  these 
commercial  technical  data  and  computer  software  licenses  and  these  must  be  adjudicated. 
Some  of  these  concerns  relate  to  the  following: 

•  Subsequent  rights  to  updates,  software  maintenance  patches,  minor  version 
changes  and  substitutions  provided  at  no  additional  cost 

•  License  transferability  to  the  Government  (for  option  exercise  and 
CDRL/CLIN  delivery) 

•  Disputes  provisions 

•  Choice  of  law  provisions 

•  Payment  of  attorney’s  fees 

•  Automatic  renewal  provisions  that  violate  the  Anti-Deficiency  Act 

•  Provisions  that  prohibit  disclosure  of  license  terms/conditions 

•  Open  Source  Software  terms  that  mandate  sharing  and  posting  of  changes 
when  doing  so  may  jeopardize  national  security 

Of  course  the  Government  has  no  idea  if  any  of  these  unwanted  terms  are  embodied 
within  the  commercial  licenses  unless  the  offeror  is  instructed  to  actually  provide  all  licenses 
as  an  addendum  to  the  table  in  the  IP  Volume.  Once  provided,  the  Government  can  perform 
its  due  diligence.  There  have  been  instances  where  offerors  have  claimed  that  license  terms 
cannot  be  provided  until  the  licenses  are  executed  after  award  and  failed  to  provide  copies 
of  the  standard  licenses  normally  required  from  commercial  vendors.  This  argument  is  not 
completely  true.  While  it  is  true  that  the  final  license  will  reflect  the  actual  terms  and 
conditions  agreed  to,  virtually  every  commercial  software  product  (or  standard  technical  data 
documentation)  has  a  standard  license  that  is  at  least  the  starting  point  for  negotiating  the 
final  terms.  These  “standard”  licenses  must  be  provided  to  enable  a  thorough  proposal 
review  and  to  develop  clarification  questions,  information  requests,  and  assign  strengths, 
weaknesses,  or  deficiencies.  In  the  event  terms  that  are  not  acceptable  to  the  Government 
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are  unable  to  be  removed,  then  it  is  a  good  practice  to  establish  an  overall  Intellectual 
Property  “Risk”  rating  to  capture  the  additional  risk  to  the  Government  from  the  restrictive 
terms  as  was  discussed  earlier. 

The  Assertions  List,  generated  in  response  to  the  -7017  clause,  is  provided  for  in 
Table  6  of  the  IP  Volume  and  again  maps  the  restrictions  and  data  rights  proposed  to  the 
Government’s  requirements  laid  out  in  the  CLINs,  CDRLs,  and  SOW/PWS.  The  additional 
benefit  this  approach  establishes  is  that  the  clarity  needed  to  effectively  manage  the 
Technical  Data  and  Computer  Software  is  mandated  as  a  consideration  of  responsiveness 
to  the  solicitation.  It  is  important  to  understand  the  difference  between  Table  4,  which 
identifies  the  overall  data  rights  assigned  to  the  various  data  items,  to  Table  6,  The 
Assertions  List.  Table  4  assigns  the  data  rights,  but  Table  6  identifies  the  specific  restrictive 
items  (if  any)  that  are  tied  to  the  restrictions.  In  other  words  just  “what”  makes  the 
deliverable  Limited  Rights  technical  data.  These  assertions  are  also  required  for  those 
instances  where  the  Government  identifies  Government  Purpose  Rights  (GPR)  as  its 
minimum  and  the  contractor  proposes  GPR.  This  is  because  there  are  still  elements  or 
activities  of  GPR  that  provide  for  additional  due  diligence  on  the  part  of  the  Government 
when  sharing  with  third  parties  (additional  Non-Disclosure  Agreements,  for  example).  The 
Assertions  List  would  thus  look  similar  to  that  shown  in  Table  6. 

Table  6.  Assertions  List — Non-Commercial  Technical  Data,  Computer  Software, 

and  Computer  Software  Documentation 


Com  | 

COI.  2 

Col.  3 

Col.  41 

Col  5 

Col.  6 

Col.  7 

CLIN 

CDRL 

SOW/PWS 

Paras 

Technical 
Data  or 
Computer 
Software  to 
be 

Furnished 

with 

Restrictions 

Basis  for 
Assertion 

Asserted 

Rights 

Category 

Name  of 
Person 
Asserting 
Restrictions 

0002 

A0001 

Para  Nrs. 

0002 

A0002 

Para  Nrs. 

1.  The  instructions  for  this  column  in  Section  L  must  clearly  articulate  the  requirement  for  clanty  and 
thoroughness  in  the  item  descriptions  for  the  reasons  mentioned  earlier.  It  needs  to  be  made  clear  to 
offerors  that  cryptic  and  incomplete  descriptions  may  render  their  offer  non-responsive  to  the 
solicitation. 

The  “prior  delivery  list,”  generated  in  response  to  the  -7028  clause,  is  provided  for  in 
Table  7  and  maps  the  technical  data  and  computer  software  that  was  delivered  to  the 
Government  prior  to  the  current  effort  (or  is  scheduled  to  be  delivered  on  another  ongoing 
contract).  Readers  should  keep  in  mind,  however,  that  unless  there  were  deliveries  earlier  in 
time  (or  planned  for  the  future)  that  would  be  subject  to  reporting  in  the  table,  the  offeror  will 
simply  report  “none.”  Again,  delivery  is  paramount  for  the  successful  functioning  of  various 
clauses  and  the  rights  they  impose.  In  addition  to  the  standard  information  required,  the 
relevant  CDRLs  are  identified,  as  well  as  all  contract  information  from  which  the  items 
were/are  to  be  delivered  that  are  identical  or  substantially  similar  to  documents  or  other 
media  that  the  offeror  has  produced  for,  delivered  to,  or  is  obligated  to  deliver  to  the 
Government  under  any  contract  or  subcontract  (DFARS  252.227-7028). 
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Table  7.  Prior  Delivery  List  for  Technical  Data  or  Computer  Software 


CoL  1 

CoL  2 

Col.  3' 

Col.  4 

Col.  5 

CoL  6 

Col.  7 

CoL  3 

Col.  9 

CLIN 

CDRL 

TD/CS 

Previously 

Delivered 

Contract 
Nr  Under 
Which 
Data  Was 
Produced 

Contract  Nr. 

Under 
Which  Data 
Was  Most 
Recently 
Delivered  or 
Will  Be 
Delivered 

Organization 
Name  & 
Address  to 
Which  the 
Data  Was  or 
Will  Be 
Delivered 

Delivery 

Date 

Limitations 
on  Govt's 
Right  to  Use 
or 

Disclosure 

Data 

Date 

Li  m  Station  (s) 
Expire 

0002 

A0OQ1 

0002 

AQ0Q2 

*  The  instructions  for  this  column  in  Section  L  must  clearly  articulate  the  requirement  for  clarity  and 
thoroughness  in  the  item  descriptions  for  the  reasons  mentioned  earlier.  It  needs  to  be  made  clear  to 
offerors  that  cryptic  and  incomplete  descriptions  may  render  their  offer  nonresponsive  to  the  solicftation. 
In  addition,  rf  firmware  is  to  be  delivered,  the  data  item  title  should  include  the  CUN  noun  description  that 
the  firmware  will  be  embedded  into. 


Table  8  constitutes  the  identification  of  any  Special  Licenses  relevant  to  a  specific 
CDRL  data  item.  It  is  important  that  the  scope  or  terms  and  conditions  of  any  special  license 
be  clearly  articulated  in  the  proposal  and  a  copy  of  the  actual  license  to  be  executed  be 
provided  as  an  Addendum  to  Table  8  for  subsequent  review,  evaluation  by  the  Government, 
and  incorporation  into  the  contract  as  an  attachment.  A  notional  format  for  Table  8  can  be 
found  below. 

Table  8.  Specifically  Negotiated  Licenses  (Special  Licenses) — Non-Commercial 

Technical  Data  and  Computer  Software) 


Coil.  1  |  CoL  2 

Col.  3 

Col.  4 

CLIN 

CDRL 

SOW/PWS 

Paras 

Special 

License 

Title/Number 

/Version1 

0002 

A0001 

Para  Nrs. 

0002 

A0002 

Para  Nrs. 

1 .  The  in  structions  for  thi  s  c  olumn  i  n  Section  L  m  ust  clearly  comm  un  ic  ate  that  the  sc  o  pe  of  th  e  lie  ense 
must  be  articulated  and  provided  with  the  proposal.  This  includes  identifying  who  the  CDRL  may  be 
released  or  disclosed  to,  the  purposes  of  the  license,  and  the  period  of  time  it  shall  be  in  effect.  The 
instructions  must  also  require  attaching  the  Special  License  as  an  addendum  to  Table  3  in  the  IP 
Volume. 

Table  9  provides  the  insight  to  any  inventions  the  contractor  plans  to  incorporate  into 
any  component,  item,  or  process.  A  “background  invention”  is  any  invention,  other  than  a 
subject  invention,  that  is  covered  by  any  patent  or  pending  patent  application  in  which  the 
offeror  (including  its  sub-offerors  or  suppliers,  or  potential  sub-offerors  or  suppliers  at  any 
tier)  (1)  has  any  right,  title,  or  interest;  and  (2)  proposes  to  incorporate  into  any  items, 
components,  or  processes  to  be  developed  or  delivered,  or  that  will  be  described  or 
disclosed  in  an  technical  data,  computer  software,  or  computer  software  documentation  to 
be  developed  or  delivered  under  the  resulting  contract  (DoD,  May  2013).  This  table  contains 
six  columns. 
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Table  9.  Rights  in  Background  Inventions1 


Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

CLIN 

CDR 

L 

SOW/PW 

S  Paras 

Patent 

Title/Serial 

Nr. 

Patent 

Date 

Patent 

Holder 

Name(s) 

0002 

A000 

1 

Para  Nrs. 

0002 

A000 

2 

Para  Nrs. 

1 .  The  Patent  rights  clauses  of  the  solicitation  provide  additional  guidance  regarding  the  identification  and 
management  of  inventions  used  on  the  contract.  The  purpose  of  this  table  is  to  capture  the 
inventions/patents  to  be  incorporated  in  one  place  as  an  attachment  to  the  contract  to  preclude  losing 
their  identity  as  part  of  the  technical  baseline  after  the  initial  award  is  completed.10 

Table  10  provides  the  insight  to  any  third-party  patent  rights  for  which  the  contractor 
plans  to  pay  royalties.  This  table  provides  information  concerning  these  third-party  patents 
and  the  amount  of  the  royalties  it  will  pay  in  order  to  perform  under  the  contract.  This  table 
contains  seven  columns. 


Table  10.  Third  Party  Patent  Rights  and  Royalties1 


Col.  1 

Col.  2 

Col.  3 

Col.  4 

Col.  5 

Col.  6 

Col.  7 

CLIN 

CDRL 

SOW/PWS 

Paras 

Patent 

Title/Serial 

Nr. 

Patent 

Date 

Patent 

Holder 

Name(s) 

Royalties 
to  be 
Paid 

0002 

A000 

1 

Para  Nrs. 

0002 

A000 

2 

Para  Nrs. 

1.  See  FAR  Clause  52.227-6  for  specific  guidance  on  Royalties.  This  language  (and  table)  only  becomes 
relevant  if  a  third-party  patent  is  included  in  the  technical  solution  proposed  (or  incorporated  post  award). 

The  purpose  of  this  table  is  to  capture  the  patent  royalty  to  be  paid  in  one  place  in  an  attachment  to  the 
contract  to  preclude  losing  their  identify  as  part  of  the  technical  baseline  after  the  initial  award  is  completed. 

Communicating  the  Government’s  Expectations  Is  Vital  to  Success 

The  acquisition  team  crafting  the  RFP  needs  to  pay  close  attention  when  drafting  the 
instructions  in  Section  L  related  to  the  Intellectual  Property  Volume.  Explaining  what  is 
needed  within  the  various  tables  ensures  all  offerors  have  a  common  understanding.  Trying 
to  avoid  specifying  the  “table  format”  and  just  provide  Section  L  language  tends  to  give 
inconsistent  results  and  lead  to  more  clarifications  and/or  discussions.  Some  offerors  will 
interpret  the  instructions  differently,  and  the  result  is  data  rights  information  spread  across 
the  proposal  and  is  a  virtual  “scavenger  hunt”  to  figure  out  just  what  IP  impacts  there  are  in 


10  The  identification  of  inventions  to  be  used  in  a  contractors  technical  solution  described  in  their 
proposal  is  normally  required  in  Section  K  of  the  solicitations.  This  completed  section  is,  however, 
buried  in  the  contract  file  documentation  at  contract  award  and  can  be  difficult  to  locate  in  a 
voluminous  contract  file.  The  table  methodology  presented  here  keeps  it  at  the  forefront  of  the 
acquisition  team  to  manage  throughout  the  contract  period  of  performance. 
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offerors’  proposals.  The  best  approach  is  a  Tabular  One  by  IP  topic  and  then  incorporate  the 
individual  tables  as  “Tabs,”  with  clear  instructions  to  populate  the  tables.  Finally,  the 
Government  must  ensure  that  updates  to  the  various  IP  tables  in  the  IP  Attachment  are 
reviewed  and  approved  prior  to  incorporating  the  technical  changes  reflected  in  the 
projected  updates  during  post  award  performance.  This  is  to  ensure  configuration 
management  of  the  technical  changes  is  carefully  managed  and  maintained. 

Open  Systems  Architecture  (OSA) — Where  Does  It  Fit? 

Open  Systems  Architecture  provides  for  designs  that  accommodate  updated 
technology  (data  and  computer  software)  by  leveraging  modular,  loosely  coupled  and  highly 
cohesive  components  within  a  system.  A  system  should  be  designed  in  major  “modules” 
where  potentially  proprietary  data  and/or  computer  software  is  “encapsulated”  (i.e., 
segregated  within  the  design).  These  modules  must  be  “loosely  coupled”  whereby  individual 
modules  do  not  depend  upon  each  other  to  enable  the  entire  system  to  function.)  Lastly,  the 
modules  must  be  highly  cohesive  so  the  module  functionality  works  together  via  common 
standards.  The  system  relies  on  open  interfaces  well  known  by  all  competitors  to  enhance 
future  competitions  as  well  as  more  effective  sustainment  and  supportability.  This  approach 
enables  even  highly  restrictive  and  even  proprietary  designs  to  be  incorporated  into  the  final 
system  yet  still  enable  technology  insertion  with  new  and  innovative  upgrades.  It  is  only 
made  possible,  however,  if  the  “critical”  IP  components  are  or  have  been  delivered  to  the 
Government  earlier  in  the  system’s  life  cycle.  Knowing  where  the  IP  is  embedded  within  the 
various  designs  fosters  this  approach  as  well  by  enabling  strategic  decisions  where  to  focus 
on  “opening  up”  the  system  for  more  competition  and  technology  insertion.  The  IP  Volume 
discussed  earlier  provides  for  the  situational  awareness  necessary  to  bring  it  all  together. 

For  a  thorough  discussion  on  Open  Systems  Architecture  and  multiple  examples  and 
guides,  readers  should  review  the  OSA  Guidebook  for  Program  Managers  (DoD,  May  2013). 

Government  Insistence  on  Additional  Openness  and  IP  Rights — Is  It  Viable? 

It  is  important  to  discern  whether  or  not  the  Government,  in  implementing  the 
processes  and  strategies  presented  here  can  be  sustained  and  implemented  when 
challenged  by  Industry.  There  are  numerous  Government  Accountability  Office  (GAO)  bid 
protest  decisions  that  have  upheld  the  Government’s  decisions  which  supports  the  concepts 
presented  herein.  What  is  important  to  take  away  from  these  decisions  are  some  key 
principles  that  when  adhered  to,  result  in  new  IP  and  OSA  strategies  that  are  executable 
and  sustainable  when  challenged. 

As  stated  earlier,  if  the  Government  establishes  a  plan  to  evaluate  proposals  (a 
source  selection  plan),  follows  the  plan,  consistently  applies  the  criteria  and  their  standards 
fairly  to  all  offerors,  then  makes  a  best  value  decision  based  upon  all  evaluation  areas  (cost 
and  non-cost),  the  GAO  will  not  overturn  the  Government’s  decision.  This  has  been  a 
consistent  result  in  multiple  bid  protest  decisions.  Can  the  Government  use  Open 
Architecture  as  a  criteria  in  source  selection?  Can  it  require  offerors  to  clearly  identify  what 
data  rights  the  Government  will  obtain  with  an  offeror’s  proposed  design/solution?  Finally, 
can  the  Government  make  a  best  value  decision  using  Open  Systems  Architecture 
(OSA/OA)  and  the  delivered  data  rights  for  the  technical  data  and  computer  software 
artifacts?  The  answer  to  all  is  unequivocally,  yes. 
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A  recent  bid  protest  concerning  an  Engagement  Skills  Training  (EST)  system  will 
help  illustrate.11  In  this  instance,  the  Government  provided  for  an  Open  Architecture 
subfactor  to  assess  the  ability  of  the  offeror’s  design  to  “fully  support,  maintain,  and  modify 
the  EST  software  and  technical  data  throughout  the  program  life  cycle  to  include  the  legacy 
EST  systems,  weapons  and  scenarios.”12  The  acquisition  team  evaluated  the  proposals 
using  the  scales  and  criteria  called  out  in  their  RFP.  During  the  evaluation  the  team 
identified  several  areas  where  the  Government’s  license  rights  were  cited  inconsistently  in 
different  sections  of  an  offeror’s  proposal.  Because  of  this,  the  evaluation  team  was  unsure 
just  what  rights  the  Government  would  receive.  A  lower  “marginal’  rating  under  the  open 
architecture  subfactor  was  then  assigned.  The  ambiguity  was  created  by  the  offeror  in  the 
errors  it  submitted  related  to  a  material  aspect  of  the  technical  approach  regarding  open 
architecture.13  Specifically,  the  inability  of  the  Government  to  share  many  IP  artifacts  of 
technical  data  and  computer  software.  The  unsuccessful  offeror  challenged  other  areas  of 
the  evaluation  but  these  will  not  be  recounted  here  for  the  sake  of  brevity.  The  lessons 
learned  are  important,  however.  First,  if  the  Government  communicates  what  it  will  evaluate, 
how  it  will  evaluate,  and  what  will  be  taken  into  consideration  in  the  best  value  decision,  the 
GAO  will  support  the  Government’s  decision.  Second,  it’s  not  the  Government’s  job  to 
“rewrite”  the  offeror’s  proposals  and  identify  each  and  every  error  and  weakness  identified. 
The  FAR  requires  agencies  conducting  discussions  with  offerors  to  address,  “at  a  minimum 
...  deficiencies,  significant  weaknesses  and  adverse  past  performance  information  to  which 
the  offeror  has  not  yet  had  an  opportunity  to  respond”  (FAR  15.306(d)(3)).  The  Government 
does  not  have  to  “spoon  feed”  an  offeror  as  to  each  and  every  item  that  could  be  revised  to 
improve  and  offeror’s  proposal.14  Finally,  data  rights  can  be  directly  rated  and  scored  in  a 
competitive  source  selection  to  enable  the  Government  to  make  a  best  value  decision. 

In  another  bid  protest  decision,  the  Governments  requirement  was  for  a  commercial 
off-the-shelf,  “web-based,  automated  e-Recruitment  solution,  including  all  software,  software 
documentation,  implementation  support,  and  services  to  support  the  full  life  cycle  of  an 
enterprise-wide  hiring/recruitment  system.”15  An  unsuccessful  offeror  did  not  include  an 
adequate  explanation,  as  requested  by  the  solicitation,  of  the  proposal’s  compliance  with  the 
solicitation’s  minimum  mandatory  requirements  concerning  intellectual  property/data  rights.16 
At  issue  were  terms  of  the  license  whereby  the  agency’s  data  once  entered  into  the  offeror’s 
database  became  the  property  of  the  offeror.  This  was  because  a  term  of  the  license 
required  all  data  be  identified  prior  to  contract  start.  Since  the  goal  of  the  project  was  to 
manage  employment  and  other  HR  data  throughout  the  period  of  performance,  this  did  not 
meet  a  material  requirement  of  the  RFP  which  was  clearly  called  out  in  a  mandatory 
“functional  requirements  matrix.”  The  offeror’s  proposal  was  scored  commensurately  and 
they  were  eliminated  from  the  competitive  range.  This  protest  illustrates  a  critical  lesson 
relevant  to  our  discussion  here.  Namely,  establishing  material  requirements  in  an  RFP  is 
something  that  standard  commercial  licenses  may  be  in  conflict  with.  Recall  the  language  in 
both  the  “Scoring”  and  “Risk”  approaches  to  evaluating  IP  discussed  earlier.  In  both, 


11  See  GAO  Bid  Protest  B-410006;  B-410006.2,  dated  October  8,  2014. 

12  See  GAO  Bid  Protest  B-410006;  B-410006.2,  dated  October  8,  2014. 

13  See  GAO  Bid  Protest  B-410006;  B-410006.2,  dated  October  8,  2014. 

14  See  GAO  Bid  Protest  B-404671 .2,  B404671 .4,  dated  April  8,  201 1 . 

15  See  GAO  Bid  Protest  B-298380.4,  dated  June  1 1 , 2007. 

16  See  GAO  Bid  Protest  B-298380.4,  dated  June  1 1 , 2007. 
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inconsistency  with  the  “requirements  of  the  RFP”  and  “satisfaction  of  Government  user 
needs  as  set  forth  in  the  solicitation”  were  key  discriminators.  Thus,  “hiding  behind  the 
commercial  item  veil”  as  it  were,  to  claim  that  a  standard  commercial  license  may  not  be 
challenged  regarding  its  terms  and  conditions  is  not  sufficient  to  negate  the  basic  needs  of 
the  Government  for  IP  that  effectively  meet  their  needs.  What  is  important  is  to  provide  an 
adequate  license  to  meet  the  Government’s  requirements  called  out  in  an  RFP. 

Offerors  should  provide  their  best  initial  proposal  in  response  to  the  Government’s 
RFP  or  risk  being  eliminated  from  the  competitive  range.  This  is  an  important  point  to 
understand  as  was  illustrated  in  a  recent  bid  protest  where  an  offeror  failed  to  provide 
significant  material  data  and  information  required  by  RFP  In  Section  L.17  The  GAO  has 
opined  previously  that  “an  offeror  has  the  responsibility  to  submit  a  well-written  proposal, 
with  adequately  detailed  information  that  clearly  demonstrates  compliance  with  the 
solicitation  requirements  and  allows  a  meaningful  review  by  the  procuring  agency.”18  The 
offeror  in  this  instance  admitted  it  failed  to  provide  information  requested  by  the  RFP  and  as 
a  result  their  proposal  failed  to  demonstrate  that  it  met  the  solicitation  requirements  and  they 
were  eliminated  from  the  competitive  range.  The  lesson  relevant  to  the  discussion  here, 
specifically  to  the  IP  Summary  AttachmentA/olume  described  earlier,  is  that  unless  an 
offeror  pays  close  attention  to  the  detailed  instructions  for  this  volume  they  run  the  risk  of 
being  eliminated  from  the  competitive  range.  This  is  especially  true  when  IP  and  the 
associated  license  rights  and  license  terms  and  conditions  are  necessary  to  make  a  best 
value  decision  that  has  decision  criteria  based  on  IP  and/or  Open  Architecture. 

Conclusion 

The  goal  of  this  paper  was  three-fold:  first,  to  present  the  acquisition  professional 
with  some  tools  to  ensure  the  Government  gets  the  intellectual  property  rights  it  needs  to 
procure,  support,  and  sustain  the  systems  the  warfighter,  and  others,  need;  second,  to 
provide  a  structure  and  process  to  get  these  rights  identified  on  contract  while  providing 
transparency  into  them  throughout  the  period  of  performance  and  not  finding  out  “upon 
delivery”  what  rights  are  really  being  delivered;  and  finally,  to  present  a  different  way  to  look 
at  the  “necessary”  rights  when  viewed  from  an  open  architecture  perspective.  This  is 
facilitated  by  strategically  seeking  the  “necessary”  IP  rights  (based  upon  the  Government’s 
minimum  needs)  that  focus  on  interfaces  and  other  artifacts  to  implement  an  OSA  approach. 
When  this  approach  is  implemented  at  the  onset  of  a  contract/program,  restricted  and 
limited  rights  become  mitigated  inhibitors  to  technology  insertion  and  instead  become 
catalysts  to  enable  more  affordable  support,  sustainment,  and  cost  effective  systems  and 
solutions  for  the  Government. 
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